perm filename LISP.BUG[BUG,LSP]4 blob
sn#647767 filedate 1982-03-16 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00028 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00005 00002 BUG-LISP and LISP-FORUM
C00010 00003 ∂03-Apr-81 0610 JerryB at MIT-AI (Gerald R. Barber) Improving the LISP working environment by taking a lesson from...
C00028 00004 ∂18-Jun-81 2147 Richard M. Stallman <RMS at MIT-AI> nested function definitions interfering with extensibility.
C00046 00005 ∂28-Sep-81 0617 Mark L. Miller <MILLER at MIT-AI> Suggested new lambda-list syntax
C00047 00006 ∂11-Jan-82 0932 George J. Carrette <GJC at MIT-MC> backquote trivia, for you history fans.
C00049 00007 ∂11-Jan-82 0939 HES@MIT-AI
C00056 00008 ∂11-Jan-82 1551 Don Morrison <Morrison at UTAH-20> clarification regarding backquote query
C00059 00009 ∂12-Jan-82 1446 Jon L White <JONL at MIT-MC> 'backquote' actions
C00071 00010 ∂16-Jan-82 1132 William G. Dubuque <WGD at MIT-MC>
C00090 00011 ∂25-Jan-82 2316 FININ at WHARTON-10 (Tim Finin) Interlisp and MacLisp (almost)
C00107 00012 ∂30-Jan-82 0728 kwh@MIT-AI minilisp
C00111 00013 ∂30-Jan-82 1405 Jon L White <JONL at MIT-MC> Comparison of "lambda-macros" and my "Two little suggestions ..."
C00119 00014 ∂30-Jan-82 1446 Jon L White <JONL at MIT-MC> The format ((MACRO . f) ...)
C00121 00015 ∂01-Feb-82 0752 Jon L White <JONL at MIT-MC> Incredible co-incidence about the format ((MACRO . f) ...)
C00123 00016 ∂01-Feb-82 0847 HIC at SCRC-TENEX Incredible co-incidence about the format ((MACRO . f) ...)
C00127 00017 ∂17-Feb-82 2001 Jon L White <JONL at MIT-MC> SHARPM
C00140 00018 ∂22-Feb-82 0121 Rod Brooks <ROD at SU-AI> DO loses.
C00142 00019 ∂22-Feb-82 1241 2Lt Eric J. Swenson <EJS at MIT-MC> Interlisp and MacLisp (almost)
C00144 00020 ∂22-Feb-82 1337 Glenn S. Burke <GSB at MIT-ML> DO loses.
C00148 00021 ∂23-Feb-82 2026 George J. Carrette <GJC at MIT-MC> Closing Files.
C00149 00022 ∂26-Feb-82 1319 FEINBERG at CMU-20C DSK:
C00150 00023 ∂27-Feb-82 1153 EB@MIT-ML
C00151 00024 ∂27-Feb-82 1153 Jon L White <JONL at MIT-MC>
C00153 00025 ∂27-Feb-82 1247 Jon L White <JONL at MIT-MC> Compilation bug seen in DO loop
C00172 00026 ∂06-Mar-82 1904 Alan Bawden <ALAN at MIT-ML> how am I supposed to deal with this behavior?
C00174 00027 ∂08-Mar-82 0755 Jon L White <JONL at MIT-MC> Wrong result
C00179 00028 ∂08-Mar-82 1629 FEINBERG at CMU-20C Restricted JFNs
C00188 ENDMK
C⊗;
BUG-LISP and LISP-FORUM
∂03-Apr-81 0610 JerryB at MIT-AI (Gerald R. Barber) Improving the LISP working environment by taking a lesson from...
Date: 3 APR 1981 0908-EST
From: JerryB at MIT-AI (Gerald R. Barber)
Subject: Improving the LISP working environment by taking a lesson from...
To: SHRAGE at WHARTON-10, Deutsch at PARC-MAXC
CC: LISP-FORUM at MIT-AI, nil at MIT-MC
Date: 10 Nov 1980 10:41 PST
From: Deutsch at PARC-MAXC
To: SHRAGE at WHARTON (Jeffrey Shrager)
cc: lisp-forum, nil at MIT-MC
Re: Improving the LISP working environment by taking a lesson from...
1- In Interlisp, the Masterscope facility lets you easily find out what all your
functions, variables, etc. names are. In fact, it includes a powerful query
facility for discovering relationships in your program, much better than
anything in any other language or system I know. It is callable both from the
terminal (with pleasant English-like syntax) or from programs.
2- The SYSOUT facility in Interlisp makes it very cheap (in time) to create
checkpoints which you can resume from later. Many Interlisp users prefer the
APL "workspace" style, keeping a SYSOUT around to work in for days or weeks.
3- It's not simply a matter of "cover functions", different Lisp systems have
chosen to develop themselves in quite different directions. For example, Interlisp
has put tremendous emphasis on managing the programming process through
history retention, building up a data base of your code, etc., while MACLisp has
placed more emphasis on efficient compilation and certain kinds of system
simplicity. APL hasn't grown in ANY of these directions as far as I know. To
quote Joel Moses (approximately): "APL is a diamond -- you can't add anything
to it, even another diamond, without ruining its beauty. Lisp is a ball of mud:
you can keep adding more and more mud to it and its nature doesn't change." I
think it is precisely because Lisp is really almost like an assembly language for a
particularly interesting machine that it has been used to do such a tremendous
variety of things.
Here is a copy of a message that may be of interest.
∂18-Jun-81 2147 Richard M. Stallman <RMS at MIT-AI> nested function definitions interfering with extensibility.
Date: 19 June 1981 00:44-EDT
From: Richard M. Stallman <RMS at MIT-AI>
Subject: nested function definitions interfering with extensibility.
To: LISP-FORUM at MIT-AI
Date: 18 June 1981 10:37-EDT
From: George J. Carrette <GJC at MIT-MC>
This certainly true in the case of program editing in a
non-structured text-oriented way, but in a system with
more cooperation between program editor and compiler this
need not be the case. I'm all for editing programs as text,
but I don't like representing them, storing them, as
a sequence of characters, i.e. in a purely syntactic manner.
Why? Because it severely limits program management to
purely syntactical levels.
The problem is not in editing at all. It is easy in any sort of
editor to edit the internal function definition and make no change to
the external one, and vice versa.
The problem comes when you try to store a file which, when loaded,
changes one but not the other. No editing is involved, just loading
of source or compiled files.
IRT Moon's suggestion:
Function specs like (:INTERNAL FOO BAR) for BAR within FOO make it
possible to redefine the internal function without changing the
external one. This is a good solution for that half of the problem.
But how do you redefine the external one without changing the internal
one?
∂28-Sep-81 0617 Mark L. Miller <MILLER at MIT-AI> Suggested new lambda-list syntax
Date: 28 September 1981 09:07-EDT
From: Mark L. Miller <MILLER at MIT-AI>
Subject: Suggested new lambda-list syntax
To: RMS at MIT-AI
cc: LISP-FORUM at MIT-AI
I prefer this proposal to the existing situation. Regards, Mark
∂11-Jan-82 0932 George J. Carrette <GJC at MIT-MC> backquote trivia, for you history fans.
Date: 11 January 1982 12:21-EST
From: George J. Carrette <GJC at MIT-MC>
Subject: backquote trivia, for you history fans.
To: Morrison at UTAH-20
cc: Lisp-Forum at MIT-AI
The PDP-10 Maclisp implementation of Backquote works at macroexpansion
time as you wanted. This was done for ease of GRINDEF'ing.
The Lispmachine implementation provides special synonyms for LIST, CONS,
LIST*, APPEND, etc, and uses a simple pattern matcher to create a cannonical
pretty form for GRINDEF. The NIL implementation uses code lifted from
code from which the Multics Maclisp backquote was derived, which is also
related in some way to the Lispmachine backquote.
In all implementations there are "car-position" markers for "," ",@" and ",."
and some simple entry to the "BACKQUOTIFY" function called by "`"
either at read or eval times.
Q: What is the deepest nesting of backquote found to arise in practice?
-gjc
∂11-Jan-82 0939 HES@MIT-AI
From: HES@MIT-AI
Date: 01/11/82 12:25:08
HES@MIT-AI 01/11/82 12:25:08
To: (BUG COMPLR) at MIT-AI
CC: ALAN at MIT-AI
The maclisp complr seems to generate the wrong stuff for the
code in ai:reason;foobar > ; in particluar the form
(setf (tms-support-status node) *in*)
turns into the wrong thing. Note that this code works interpretively.
My complr init loads lisp;struct fasl as does my lisp init in case this is relevant.
howie
∂11-Jan-82 1551 Don Morrison <Morrison at UTAH-20> clarification regarding backquote query
Date: 11 Jan 1982 1601-MST
From: Don Morrison <Morrison at UTAH-20>
Subject: clarification regarding backquote query
To: lisp-forum at MIT-AI
The sort of thing I had in mind for a complicated macro producing macro
was to have a macro producing macro foo consing up the final form, but
bits and pieces it stuffs in are being created by a function bar. The
value which foo finally returns will be some hairy conglomeration of
conses, lists, and appends, such as backquote is particularly good at
creating. But the pieces which bar creates will mostly be constant,
but sometimes I'd like bar to be able to return a piece which contains
a call on unquote, which unquote will be seen by the dynamically
surrounding backquote (i.e. in foo), rather than a lexically
surrounding one. Perhaps this is too complicated to be done clearly
(this description certainly is so complicated that I doubt it would
ever be clear) with backquote, but I seem to remember having created
such a beast where this seemed more perspicuous than the hard way.
Unfortunately I can't remember the exact example, and all the examples
I can now dream up don't warrant such a procedure; seems that in all my
toy examples simply adding an unquote in the caller and a backquote in
the callee works. Perhaps the "dynamic version" is never really
useful. And anyway, I gather from some of the replies that there are
functional entry points to the required pieces available in MACLISP and
friends, though I still don't know their names.
-------
∂12-Jan-82 1446 Jon L White <JONL at MIT-MC> 'backquote' actions
Date: 12 January 1982 17:38-EST
From: Jon L White <JONL at MIT-MC>
Subject: 'backquote' actions
To: Morrison at UTAH-20
cc: LISP-FORUM at MIT-MC
In MacLISP, the variable BACKQUOTE-EXPAND-WHEN determines
whether the reader-macro produces a minimal, standard, lisp form
which merely 'evaluates to the right thing', or a form with extra
evaluator macros inserted which correspond to the places where 'commas'
of various kinds appeared. Of course, the latter format 'evaluates
to the right thing' too.
The LISPM version produces a rather minimal form for evaluation, but using
internal function names rather than the standard lisp ones.
The point of having either the extra evaluator macros, or the special
internal function names, is so that a random piece of code which was
constructed up by the backquote macro can be re-parsed into a faithful
representation of the original input. The advantage of using evaluator
macros as opposed to internal subrs is that automatic code analyzers
don't have to know about these internal names (but rather would only
have to know about macroexpansion in general and the usual primitive
lisp subrs); the disadvantage of using the evaluator macro format is
that it takes an extra cons cell or so for each comma in the source input.
Note for example that there currently is no way to distinguish between the
internal forms of the following two functions:
(defun FIVE+ONE (x) '6)
(defun SIX (x) (quote 6))
whereas
(defun QUOTIFY-1 (x) `',x)
(defun QUOTIFY-2 (x) (list (quote QUOTE) x))
are distinguishable when BACKQUOTE-EXPAND-WHEN is set to EVAL (or
when other internal markers are left in).
∂16-Jan-82 1132 William G. Dubuque <WGD at MIT-MC>
Date: 16 January 1982 14:32-EST
From: William G. Dubuque <WGD at MIT-MC>
Sender: BIL at MIT-MC
To: BUG-LISP at MIT-MC
The VECTOR package seems to break LEXPR-FUNCALL, e.g.
(load '((lisp)vector))
(lexpr-funcall 'list ()) =>
;SI:CLASS-TYPEP UNDEFINED FUNCTION IN UUO CALL
∂25-Jan-82 2316 FININ at WHARTON-10 (Tim Finin) Interlisp and MacLisp (almost)
Date: 26 Jan 1982 (Tuesday) 0211-EDT
From: FININ at WHARTON-10 (Tim Finin)
Subject: Interlisp and MacLisp (almost)
To: ejs at MIT-MC
cc: lisp-forum at MIT-MC
I've been working on a general inter-dialect Lisp translation system which
specializes in Interlisp to Franz Lisp (which is very close to MacLisp). It
is still undergoing developement. It includes a general rule driven
translator, a small set of pattern-action rules for translating Interlisp into Franz,
and a Interlispy run time environment for Frnaz. At Penn, we've opted for
a system that includes both translation and emulation. Some other efforts
I'm aware of include the following:
- The Franz group at Berkeley have some sort of Interlisp compatability
package for Franz.
- An extensive Interlisp to MacLisp translation system called MACLISPIFY
was written at SRI and used to transport some large systems. I can dig
up the details if you're interested.
- The Interlisp system includes the TRANSOR package for trnaslating Interlisp
code to other Lisp dialects. There is a set of rules for Interlisp to Maclisp,
although it is somewhat dated.
- There was a Interlisp to Maclisp translation system written by Jack Holloway
(I believe) and extended by Dave McDonnald. It was used to translate
the LUNAR system to MacLisp and LispMachine Lisp (I think).
- There is a group at Stanford on SUMEX that is trying to implement some of
the Interlisp packages (e.g. the RECORD package) in Franz.
i can supply more details on some of these efforts if you are interested.
Tim
∂30-Jan-82 0728 kwh@MIT-AI minilisp
From: kwh@MIT-AI
Date: 01/30/82 10:20:21
Subject: minilisp
kwh@MIT-AI 01/30/82 10:20:21 Re: minilisp
To: lisp-forum at MIT-MC, JoSH at RUTGERS
CC: KWH at MIT-AI
Bob Kirby at the University of Maryland has a nice LISP for the 11- it is a derivative
of Maryland LISP (which runs on UNIVAC's) which is derivative from Wisconson LISP...
It has a pretty printer, a MICROPLANNER, a structure editor, and a bunch of other
stuff. Bob Kirby is in the computer science department at Maryland, so you might
want to get in touch with him- the only problem with any LISP's for the 11 is that
you are intrinsically limited by that address space- (unless you hack
virtual memory, which is hairy but possible....)
Good luck,
Ken.
p.s. Does MIT have a copy of Rutger's extended addressing LISP? Can we get
one? Is there any documentation for it I could get a copy of?
∂30-Jan-82 1405 Jon L White <JONL at MIT-MC> Comparison of "lambda-macros" and my "Two little suggestions ..."
Date: 30 January 1982 16:55-EST
From: Jon L White <JONL at MIT-MC>
Subject: Comparison of "lambda-macros" and my "Two little suggestions ..."
To: KMP at MIT-MC, hic at SCRC-TENEX
cc: LISP-FORUM at MIT-MC, common-lisp at SU-AI
[Apologies for double mailings -- could we agree on a name for a
mailing list to be kept at SU-AI which would just be those
individuals in COMMON-LISP@SU-AI which are not also on LISP-FORUM@MC]
There were two suggestions in my note, and lambda-macros relate
to only one of then, namely the first one
FIRST SUGGESTION:
In the context of ((<something> . . .) a1 a2), have EVAL macroexpand
the part (<something> . . .) and "try again" before recursively
evaluating it. This will have the incompatible effect that
(defmacro foo () 'LIST)
((foo) 1 2)
no longer causes an error (unbound variable for LIST), but will rather
first expand into (list 1 2), which then evaluates to (1 2).
Note that for clarity, I've added the phrase "try again", meaning to
look at the form as see if it is recognized explicitly as, say, some
special form, or some subr application.
The discussion from last year, which resulted in the name "lambda-macros"
centered around finding a separate (but equal?) mechanism for code-expansion
for non-atomic forms which appear in a function place; my first suggestion
is to change EVAL (and compiler if necessary) to call the regular macroexpander
on any form which looks like some kind of function composition, and thus
implement a notion of "Meta-Composition" which is context free. It would be
a logical consequence of this notion that eval'ing (FUNCTION (FROTZ 1)) must
first macroexpand (FROTZ 1), so that #'(FPOSITION ...) could work in the
contexts cited about MAP. However, it is my second suggestion that would
not work in the context of an APPLY -- it is intended only for the EVAL-
of-a-form context -- and I'm not sure if that has been fully appreciated
since only RMS appears to have alluded to it.
However, I'd like to offer some commentary on why context-free
"meta-composition" is good for eval, yet why context-free "evaluation"
is bad:
1) Context-free "evaluation" is SCHEME. SCHEME is not bad, but it is
not LISP either. For the present, I believe the LISP community wants
to be able to write functions like:
(DEFUN SEMI-SORT (LIST)
(IF (GREATERP (FIRST LIST) (SECOND LIST))
LIST
(LIST (SECOND LIST) (FIRST LIST))))
Correct interpretation of the last line means doing (FSYMEVAL 'LIST)
for the instance of LIST in the "function" position, but doing (more
or less) (SYMEVAL 'LIST) for the others -- i.e., EVAL acts differently
depending upon whether the context is "function" or "expression-value".
2) Context-free "Meta-composition" is just source-code re-writing, and
there is no ambiguity of reference such as occured with "LIST" in the
above example. Take this example:
(DEFMACRO GET-SI (STRING)
(SETQ STRING (TO-STRING STRING))
(INTERN STRING 'SI))
(DEFUN SEE-IF-NEW-ATOM-LIST (LIST)
((GET-SI "LIST") LIST (GET-SI "LIST")))
Note that the context for (GET-SI "LIST") doesn't matter (sure, there
are other ways to write equivalent code but . . .)
Even the following macro definition for GET-SI results in perfectly
good, unambiguous results:
(DEFMACRO GET-SI (STRING)
`(LAMBDA (X Y) (,(intern (to-string string) 'SI) X Y)))
For example, assuming that (LAMBDA ...) => #'(LAMBDA ...),
(SEE-IF-NEW-ATOM-LIST 35) => (35 #'(LAMBDA (X Y) (LIST X Y)))
The latter (bletcherous) example shows a case where a user ** perhaps **
did not intend to use (GET-SI...) anywhere but in function context --
he simply put in some buggy code. The lambda-macro mechanism would require
a user to state unequivocally that a macro-defintion in precisely one
context; I'd rather not be encumbered with separate-but-parallel machinery
and documentation -- why not have this sort of restriction on macro usage
contexts be some kind of optional declaration?
Yet my second suggestion involves a form which could not at all be interpreted
in "expression-value" context:
SECOND SUGGESTION
Let FMACRO have special significance for macroexpansion in the context
((FMACRO . <fun>) . . .), such that this form is a macro call which is
expanded by calling <fun> on the whole form.
Thus (LIST 3 (FMACRO . <fun>)) would cause an error. I believe this
restriction is more akin to that which prevents MACROs from working
with APPLY.
∂30-Jan-82 1446 Jon L White <JONL at MIT-MC> The format ((MACRO . f) ...)
Date: 30 January 1982 17:39-EST
From: Jon L White <JONL at MIT-MC>
Subject: The format ((MACRO . f) ...)
To: common-lisp at SU-AI
cc: LISP-FORUM at MIT-MC
HIC has pointed out that the LISPM interpreter already treats the
format ((MACRO . f) ...) according to my "second suggestion" for
((FMACRO . f) ..); although I couldn't find this noted in the current
manual, it does work. I'd be just as happy with ((MACRO . f) ...) -- my
only consideration was to avoid a perhaps already used format. Although the
LISPM compiler currently barfs on this format, I believe there will be a
change soon?
The issue of parallel macro formats -- lambda-macros versus
only context-free macros -- is quite independent; although I
have a preference, I'd be happy with either one.
∂01-Feb-82 0752 Jon L White <JONL at MIT-MC> Incredible co-incidence about the format ((MACRO . f) ...)
Date: 1 February 1982 10:47-EST
From: Jon L White <JONL at MIT-MC>
Subject: Incredible co-incidence about the format ((MACRO . f) ...)
To: common-lisp at SU-AI
cc: LISP-FORUM at MIT-MC
One of my previous messages seemed to imply that ((MACRO . f) ...)
on the LISPM fulfills the intent of my second suggestion -- apparently
there is a completely unforseen consequence of the fact that
(FSYMEVAL 'FOO) => (MACRO . <foofun>)
when FOO is defined as a macro, such that the interpreter "makes it work".
However, MACROEXPAND knows nothing about this format, which is probably
why the compiler can't handle it; also such action isn't documented
anywhere.
Thus I believe it to be merely an accidental co-incidence that the
interpreter does anything at all meaningful with this format. My
"second suggestion" now is to institutionalize this "accident"; it
certainly would make it easier to experiment with a pseudo-functional
programming style, and it obviously hasn't been used for any other
meaning.
∂01-Feb-82 0847 HIC at SCRC-TENEX Incredible co-incidence about the format ((MACRO . f) ...)
Date: Monday, 1 February 1982 11:38-EST
From: HIC at SCRC-TENEX
To: Jon L White <JONL at MIT-MC>
Cc: common-lisp at SU-AI, LISP-FORUM at MIT-MC
Subject: Incredible co-incidence about the format ((MACRO . f) ...)
Date: Monday, 1 February 1982 10:47-EST
From: Jon L White <JONL at MIT-MC>
To: common-lisp at SU-AI
cc: LISP-FORUM at MIT-MC
Re: Incredible co-incidence about the format ((MACRO . f) ...)
One of my previous messages seemed to imply that ((MACRO . f) ...)
on the LISPM fulfills the intent of my second suggestion -- apparently
there is a completely unforseen consequence of the fact that
(FSYMEVAL 'FOO) => (MACRO . <foofun>)
when FOO is defined as a macro, such that the interpreter "makes it work".
However, MACROEXPAND knows nothing about this format, which is probably
why the compiler can't handle it; also such action isn't documented
anywhere.
Of course MACROEXPAND knows about it (but not the version you looked
at). I discovered this BUG (yes, BUG, I admit it, the LISPM had a
bug) in about 2 minutes of testing this feature, after I told the
world I thought it would work, and fixed it in about another two
minutes.
Thus I believe it to be merely an accidental co-incidence that the
interpreter does anything at all meaningful with this format. My
"second suggestion" now is to institutionalize this "accident"; it
certainly would make it easier to experiment with a pseudo-functional
programming style, and it obviously hasn't been used for any other
meaning.
JONL, you seem very eager to make this be your proposal -- so be it.
I don't care. However, it works on the Lisp Machine (it was a BUG
when it didn't work) to have (MACRO . foo) in the CAR of a form, and
thus it works to have a lambda macro expand into this.
Of course, Lambda Macros are the right way to experiment with the
functional programming style -- I think it's wrong to rely on seeing
the whole form (I almost KNOW it's wrong...). In any case, the Lisp
Machine now has these.
∂17-Feb-82 2001 Jon L White <JONL at MIT-MC> SHARPM
Date: 17 February 1982 20:13-EST
From: Jon L White <JONL at MIT-MC>
Subject: SHARPM
To: ALAN at MIT-MC, GSB at MIT-MC
cc: BUG-LISP at MIT-MC
The additions to SHARPM which I mentiond about a month or so ago
are now installed in version 82 --
1) #nRddd format now works
2) #|...cruft...|# format now works, as per ALAN's request
3) the actual format of the /#-MACRO-DATALIST has been changed --
be advised if you ever depended upon it.
This change is only on MC right now, but I'll :INSTALL it "soon".
If anyone needs to back out of it, you should move LISP;SHARPM OFASL
into LISP;SHARPM FASL.
NOTE WELL: this change must correspondingly be coordinated with
the installation of EXTEND (from version 291 to 292), BITS (from
version 45 to 46), and VECTOR (from version 73 to 74) -- thus
an un-doing of SHARPM must also install LISP;* OFASL into LISP;* FASL
for these three files (for efficiency reasons, they depend upon
the format of that list).
∂22-Feb-82 0121 Rod Brooks <ROD at SU-AI> DO loses.
Date: 22 Feb 1982 0120-PST
From: Rod Brooks <ROD at SU-AI>
Subject: DO loses.
To: bug-complr at MIT-MC
I can't remember if this is a manifestation of a bug that bit me a couple
of times a few years ago, and which JONL said was too hard to fix, but
it sure surprised me. The only difference between foo and baz below is the
order of their supposedly side-effectless do steppers. I couldn't get it
to lose cdr-ing down a list, rather than using the array.
(*array 'arr 'fixnum 6)
(fillarray 'arr '(8 7 6 5 4 3 2))
(setq arr (get 'arr 'array))
(defun foo (l)
(do ((i 1 (1+ i))
(last 0 ch)
(ch (arraycall fixnum l 0)
(arraycall fixnum l i)))
((= i 5))
(print (list ch last))))
(defun baz (l)
(do ((i 1 (1+ i))
(ch (arraycall fixnum l 0)
(arraycall fixnum l i))
(last 0 ch))
((= i 5))
(print (list ch last))))
.lisp
LISP 2133
Alloc? n
*
(fasload lose fas)
34121
(foo arr)
(10 0)
(7 10)
(6 6)
(5 5) NIL
(baz arr)
(10 0)
(7 10)
(6 7)
(5 6) NIL
∂22-Feb-82 1241 2Lt Eric J. Swenson <EJS at MIT-MC> Interlisp and MacLisp (almost)
Date: 22 February 1982 15:35-EST
From: 2Lt Eric J. Swenson <EJS at MIT-MC>
Subject: Interlisp and MacLisp (almost)
To: FININ at WHARTON-10
cc: LISP-FORUM at MIT-MC
Thanks for all your help with respect to Interlisp to Maclisp translators.
I am forwarding your message to ZHARTMAN@ISIE who works with the folks who
are interested in this endeavor. I'll let them handle it from there. I
would, however, like to saty in touch with the discussion, so please CC
your responses to their questions to me. Thanks. Also, I am interested in
the SRI project used to transport large systems. Please give me any
pointers to relevant information. Thanks -- Eric
∂22-Feb-82 1337 Glenn S. Burke <GSB at MIT-ML> DO loses.
Date: 22 February 1982 16:31-EST
From: Glenn S. Burke <GSB at MIT-ML>
Subject: DO loses.
To: ROD at SU-AI
cc: BUG-complr at MIT-MC
Yes, this is that old hard-to-fix bug. The insertion of type declarations,
(defun foo (l)
(do ((i 1 (1+ i))
(last 0 ch)
(ch (arraycall fixnum l 0) (arraycall fixnum l i)))
((= i 5))
--> (declare (fixnum i last ch))
(print (list ch last))))
causes it to perform correctly. As a general rule declarations
for known-fixnum quantities, most especially inside loops as these
are, both stifle this bug and produce better code.
∂23-Feb-82 2026 George J. Carrette <GJC at MIT-MC> Closing Files.
Date: 23 February 1982 23:25-EST
From: George J. Carrette <GJC at MIT-MC>
Subject: Closing Files.
To: FEINBERG at CMU-20C
cc: BUG-MACLISP at MIT-MC
For your information: File objects get closed when they are sweeped by
the garbage collector.
So all you need to do is have Emacs cause a GC in your Lisp job (or
any other Lisp job that has your file open)!
∂26-Feb-82 1319 FEINBERG at CMU-20C DSK:
Date: 26 February 1982 16:08-EST (Friday)
From: FEINBERG at CMU-20C
To: Bug-Maclisp at MC
Subject: DSK:
Howdy!
What is the status of fixing the the bug where someone
redefines DSK: to a list of things, and then Maclisp breaks? Another
user has just been screwed by this.
∂27-Feb-82 1153 EB@MIT-ML
From: EB@MIT-ML
Date: 02/27/82 12:58:24
EB@MIT-ML 02/27/82 12:58:24
To: JONL at MIT-MC
CC: (BUG MACLISP) at MIT-ML
ARYFIL and such are all very nice, but why does it use restricted
JFN's in the first place?????
∂27-Feb-82 1153 Jon L White <JONL at MIT-MC>
Date: 27 February 1982 13:28-EST
From: Jon L White <JONL at MIT-MC>
To: eb at MIT-ML
cc: BUG-MACLISP at MIT-MC, feinberg at CMU-20C
EB@MIT-ML 02/27/82 12:58:24
ARYFIL and such are all very nice, but why does it use restricted
JFN's in the first place?????
They aren't "restricted" -- they are "frozen" accesses. I suspect that
Feinberg was confused. "Frozen" means that any number of readers can gain
access, but at most one writer can have APPEND access (I don't think you
can get random write access from within LISP). A file opened for ordinary
write access isn't visible in the catalogue until it is closed; maybe
that's what caused Feinberg to think it was "restricted". Any comments Neal?
P.S.: I'm using version 2129 at MIT-XX -- I notice that CMUC still has version
2122 from last fall; hopefully this won't make a diference, but I'll
send a note to Zubkoff to suggest the possibility of an update for CMUC.
∂27-Feb-82 1247 Jon L White <JONL at MIT-MC> Compilation bug seen in DO loop
Date: 27 February 1982 15:05-EST
From: Jon L White <JONL at MIT-MC>
Subject: Compilation bug seen in DO loop
To: ROD at MIT-MC
cc: BUG-COMPLR at MIT-MC
Yes, the bug you noticed in "baz" below is a manifestation of the
local-variable-side-effected-by-fixnum-value bug, which you (and
a handful of others, notably GLR) discovered some time ago. The
simplest way to avoid this COMPLR problem is to declare such local
variable as FIXNUM, since it is the lack such declaration which
permits the bug to be seen; I've added a DECLARE in caps below to
indicate it. The declaration isn't necessary in "foo" since the
side-effects don't occur at the wrong time there, but it won't hurt
anything by having it (may even make the code marginally faster).
Date: 22 Feb 1982 0120-PST
From: Rod Brooks <ROD at SU-AI>
. . .
(defun foo (l)
(do ((i 1 (1+ i))
(last 0 ch)
(ch (arraycall fixnum l 0)
(arraycall fixnum l i)))
((= i 5))
(DECLARE (FIXNUM CH))
(print (list ch last))))
(defun baz (l)
(do ((i 1 (1+ i))
(ch (arraycall fixnum l 0)
(arraycall fixnum l i))
(last 0 ch))
((= i 5))
(DECLARE (FIXNUM CH))
(print (list ch last))))
∂06-Mar-82 1904 Alan Bawden <ALAN at MIT-ML> how am I supposed to deal with this behavior?
Date: 6 March 1982 22:04-EST
From: Alan Bawden <ALAN at MIT-ML>
Subject: how am I supposed to deal with this behavior?
To: BUG-COMPLR at MIT-ML
(defun test (x y)
(declare (fixnum x y))
(plus x y))
compiles into:
(LAP TEST SUBR)
(ARGS TEST (() . 2))
(MOVE 7 0 1)
(ADD 7 0 2)
(JSP T FXCONS)
(POPJ P)
()
This is incorrect. Nowhere did I specify that the sum of x and y was a fixnum
too.
Similarly:
(defun test (x y)
(plus (1+ x) (1+ y)))
Compile into:
(LAP TEST SUBR)
(ARGS TEST (() . 2))
(MOVE 7 0 1)
(ADDI 7 1)
(MOVE 10 0 2)
(ADDI 10 1)
(ADD 7 10)
(JSP T FXCONS)
(POPJ P)
()
Same bug.
∂08-Mar-82 0755 Jon L White <JONL at MIT-MC> Wrong result
Date: 8 March 1982 10:51-EST
From: Jon L White <JONL at MIT-MC>
Subject: Wrong result
To: JSOL at USC-ECLC
cc: BUG-MACLISP at MIT-MC, Feinberg at CMU-20C
Date: Friday, 5 March 1982 09:19-PST
From: Jonathan Alan Solomon <JSOL at ECLC>
Subject: Terminology and resolution of "restricted JFN" problem; and functions OPENF and TNX-GTJFN
Seems to me that you can do it without "restricting the JFN". If you
open the file "restricted access", which uses the following bit
(excerpt from INFO's JSYS node):
B29(OF%RTD) Allow restricted access (i.e., allow
only one process to access the file).
You will get the desired results (no other process can hack the file),
while at the same time, INFORMATION (ABOUT) FILE will show it. Note,
this is for the OPENF jsys, not for the GTJFN jsys. The JFN is
available, but the file is locked.
I believe that what was desired was that the JFN be "protected" from
mungeing by random subforks, but that the file access *not* be restricted.
That is, it's ok for several forks/jobs to open the file for simultaneous
reading; the "frozen" access, by default, prohibits more than one user at
a time from gaining write/append access.
∂08-Mar-82 1629 FEINBERG at CMU-20C Restricted JFNs
Date: 8 March 1982 19:26-EST (Monday)
From: FEINBERG at CMU-20C
Subject: Restricted JFNs
To: Jonl at MC
CC: Bug-Maclisp at MC, Bug-Twenex at XX
Howdy!
Sorry, but you are inaccurate about Teco. Teco does indeed
have subforking capability (the FZ command). It uses this capability
to make Babyl work, and to make spelling correction possible. In
almost every case of the GTJFN command, you never specify the JFN
number you want, it finds a free JFN for you. I don't understand your
paranoia about this issue, however I feel a compromise can be reached.
Why not have a global flag which determines whether or not Maclisp
should use restricted JFNs? The default can even be paranoia mode.
This is very easy to implement efficiently. The only other objection
I can see for this is that no one wants to write the code for it. In
that case, I would be glad to implement this feature. ARYFIL is just
not an acceptable solution for me, and I am willing to do something
about it. I am not the only person who wants this fixed, either.
0=E2j7πIkAI↓↓ 1QL&>+?K∨*α)9α≡ KK↔'#∃↓r<R
βπ"α6&Qlj
yhR∪πS+Q↓EY∧kπK∂B↓Eea∩↓Eei#⊃6⊗N h*≠K}iiα∨.{K∨∃∧Q9α∂∂∪K↔S&)↓r≡T→βπQ∧j&Q6l→x4*&yiαN|b⊗eβ∂!α6&"j6
1∧"∞Aβ∂!α6&"j6 4V≠
iα∃*≥62M~Aβπ"α6&Qlj 4(hR∪=βN{Uβ∨/KMβK. 33eε+cC↔∨!βS=π≠↔∃β↔+∨MβNqβS#*α7π∂fKOAβ⊗+π∪↔∩β≠'c.!|4*>+↔↔↔WSki1∧Iβ∪?r;Qβ .c'↔[*β'Q9¬K?Uβ≡ 9βπg;πgMπ;K'S*β?;∃πK?WK≡+3→βNp4+3O≠A1βf{π⊃α,)ir≡T→:2&≥↓zJ⊗ "⊗I:4
N11ε∪WQβ&C↔9β&C∃βS'I7CK/≠∂π9π;?9∨ h++'6)1βOzβ3?π"α.6A?→βKW⊗{WQβF ;∪3/⊃β≠K}iα⊗∃Sb≡*
tb&NAu∩V :4
N18hR∪?9?!β3'↑)βS#*β↔[πg+πS?∪yα←↔fa1βK/β3π∂*βS#π"βS?=ph*/↔/↓β'Qπ+A1β∞s⊃βg␈)βO?}qβKWrβ?WQε{→β∂␈∪∃84Ph(4(